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Executive  Summary 

This  report  provides  an  overview  of  the  application  engineering  Workbench  developed  by  Lockheed 
Martin  Astronautics  under  the  Reusable  Software  Architecture  for  Spacecraft  (RSAS)  contract  to  the  Air 
Force  Research  Laboratory  (AFRL)  Space  Vehicles  Directorate.  The  RSAS  Workbench  was  developed  on 
a  contract  that  had  as  its  primary  objective  the  creation  of  an  application  engineering  tool  for  the  spacecraft 
flight  software  domain.  It  incorporates  a  domain  decision  model  that  is  used  to  determine  the  selection  and 
possible  tailoring  of  reusable  components  for  the  instantiation  of  domain  applications.  Workbench  users 
specify  application  attributes  via  a  graphical  interface.  They  are  assisted  by  context-sensitive  on-line  help 
information  that  is  available  through  a  Web  browser  such  as  Netscape®. 

The  RSAS  Workbench  development  effort  benefited  from  data  developed  in  a  concurrent  Independent 
Research  and  Development  (IR&D)  project  that  the  contractor,  Lockheed  Martin  Astronautics  (LMA),  was 
conducting  at  the  time.  The  IR&D  focused  on  the  development  of  reusable  flight  software  components. 
Domain  engineering  was  performed  for  three-axis  stabilized  spacecraft.  This  activity  resulted  in  a  generic 
spacecraft  system  architecture,  reusable  software  components,  and  an  associated  decision  model  that  were 
subsequently  used  in  the  RSAS  Workbench. 

The  Workbench  was  installed  at  the  AFRL  Space  Vehicles  Directorate  ready  to  incorporate  software 
components  beyond  those  provided  through  LMA’s  IR&D  effort.  In  addition,  it  was  installed  in  LMA’s 
Spacecraft  Technology  Center  II  as  well  as  in  the  Lockheed  Martin  Missiles  and  Space  (LMMS)  Spacecraft 
Product  Center  in  Sunnyvale  where  in  December  1997  it  was  used  to  support  a  successful  demonstration 
of  an  application  engineering  process  for  the  SBIRS  (Space-Based  Infrared  System)  Program. 

Although  the  Workbench  was  developed  to  simplify  and  automate  the  reuse  of  spacecraft  flight  software,  it 
facilitates  application  engineering  in  any  product-line  environment  where  the  reuse  of  assets  is  governed  by 
a  complex  decision-making  process.  It  can  be  adapted  for  non-spacecraft  applications  where  domain 
engineering  tasks  have  been  completed.  The  Workbench  is  installed  at  the  AFRL  Space  Vehicles 
Directorate  as  well  as  at  LMA  in  Denver  and  LMMS  in  Sunnyvale. 
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Introduction 

The  establishment  of  a  product-line  engineering  environment  is  viewed  with  increasing  interest  as  the 
solution  to  the  achievement  of  cost  and  schedule  reductions  for  the  development  of  complex  systems. 
Realization  of  the  expected  benefits  in  this  approach  requires  the  performance  of  two  major  activities.  The 
first  activity — called  “domain  engineering” — involves  the  in-depth  analysis  and  modeling  of  the  domain 
with  the  resulting  development  of  standardized  components  that  are  used  to  produce  (“instantiate”)  specific 
applications.  The  second  activity — called  “application  engineering” — involves  the  systematic  use  of 
processes  and  tools  to  instantiate  domain  applications  based  on  specific  mission  needs  and  requirements. 
The  domain  engineering  activity  produces  a  generic  domain  architecture,  compatible  generic  application 
components  that  can  be  tailored  in  pre-defmed  ways,  and  a  decision  model  that  captures  the  expertise  and 
lessons  learned  needed  to  instantiate  an  application.  Domain  engineering  has  been  the  dominant  focus  of 
efforts  to  establish  product-lines  within  the  aerospace  industry  and  has  successfully  produced  numerous 
inventories  of  reusable  components  for  both  hardware  and  software  applications.  In  comparison,  efforts 
in  application  engineering  are  at  an  early  stage  of  maturation. 

This  report  provides  a  comprehensive  overview  of  a  tool — called  the  “Workbench” — that  significantly 
advances  the  state-of-the-art  for  application  engineering  in  a  reuse-based  development  environment.  The 
Workbench  incorporates  a  domain  decision  model  that  captures  knowledge  from  domain  experts.  This 
intelligence — developed  during  domain  engineering — enables  the  Workbench  to  select  and  tailor  reusable 
components  needed  to  instantiate  applications.  Domain  lessons  learned  can  be  incorporated  as  decisions, 
thereby  automating  their  use  in  application  engineering.  The  tool  guides  the  user  through  the  decision¬ 
making  process  by  means  of  user-friendly  graphical  screens,  and  captures  the  user’s  decisions  for  later 
use.  It  can  be  used  to  support  programs  from  early  application  prototyping  through  final  application 
production. 

A  discussion  of  the  Workbench  background  is  presented  in  the  next  section  of  this  report.  This  is 
followed  by  a  description  of  Workbench  in  terms  of  its  current  application  domain  and  features.  A 
description  of  domain  adaptation  process  and  cost  is  presented  next.  The  final  section  herein  provides  a 
summary  of  this  report. 

Workbench  Background 

Under  a  four-year  research  and  development  contract  that  concluded  successfully  in  April  1998,  Lockheed 
Martin  Astronautics  (LMA)  developed  a  Workbench  tool  that  facilitates  application  engineering  in  a 
product-line  environment.  This  work  was  performed  under  the  Reusable  Software  Architecture  for 
Spacecraft  (RSAS)  contract  to  the  Air  Force  Research  Laboratory  (AFRL)  Space  Vehicles  Directorate.  It 
had  as  its  key  objective  the  development  and  implementation  of  technology  that  could  simplify  software 
reuse  and  reduce  the  associated  cost  for  the  development  of  spacecraft  flight  applications.  Workbench 
technology  is  not  domain  specific  although  it  was  developed  for  spacecraft  applications.  It  can  facilitate 
recurring  application  engineering  in  any  development  environment  where  the  intelligent  reuse  of  assets  is 
governed  by  a  complex  decision-making  process. 


The  RSAS  Workbench  development  effort  benefited  from  data  developed  in  a  concurrent  Independent 
Research  and  Development  (IR&D)  project  that  LMA  was  conducting  at  the  time.  The  IR&D  focused  on 
the  development  of  reusable  flight  software  components.  Domain  engineering  was  performed  for  three- 
axis  stabilized  spacecraft.  As  part  of  this  activity,  a  survey  was  conducted  to  gather  spacecraft  system 
requirements  from  seven  independent  flight  projects  spanning  defense,  civil,  and  commercial  systems. 
The  survey  included  an  examination  of  academic  approaches  to  flight  system  specification  and  design,  and 
numerous  discussions  with  subsystem  experts.  The  resulting  flight  subsystem  requirements  were 
captured  in  a  Functional  Requirements  Matrix  (FRM).  The  diversity  of  projects  surveyed,  and  the 
accompanying  research,  provided  a  comprehensive  view  of  common  flight  system  requirements  as  well  as 
differences  among  flight  systems.  The  seven  flight  systems  included  in  the  survey  are  identified  in  Table 
1. 
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Table  1  Flight  Systems  Surveyed 


Program  Name 

Customer 

Market  Sector 

Orbit  Type 

GE-1  (A2100) 

GE  Americom 

Commercial 

Geostationary 

Communications 

NASA-JPL 

Civil 

Interplanetary/ 
Low  Altitude 

Scientific 

Brilliant  Pebbles 

SDIO 

Defense 

Classified 

Missile  Defense 

Lunar  Resource 
Mapper 

NASA-JPL 

Civil 

Interplanetary/ 
Low  Altitude 

Scientific 

Earth  Observation 
System 

NASA-Goddard 

Civil 

Low  Earth  Orbit 

Remote  Sensing 
/Earth  Science 

SDIO 

Defense 

Classified 

Remote  Sensing 

P-81 

Classified 

Defense 

Classified 

Classified 

The  typical  spacecraft  system  consists  of  eight  subsystems:  Guidance,  Navigation  and  Control; 
Communications;  Command  and  Data  Handling;  Electrical  Power;  Thermal;  Structures  and  Mechanisms; 
Propulsion;  Payload.  This  general  allocation  of  system  functionality  and  the  FRM  were  used  as  inputs  to 
the  detailed  object-oriented  domain  analysis  and  modeling  tasks  performed  by  the  IR&D.  These  tasks 
supported  the  identification  of  capabilities  needed  in  an  application  engineering  tool.  In  addition,  they 
resulted  in  a  generic  spacecraft  system  architecture,  reusable  software  components,  and  an  associated 
decision  model  that  were  subsequently  used  in  the  RSAS  Workbench. 

The  Workbench  was  installed  at  the  AFRL  Space  Vehicles  Directorate  ready  to  incorporate  software 
components  beyond  those  provided  through  the  LMA  IR&D  effort.  In  addition,  it  was  installed  in  LMA’s 
Spacecraft  Technology  Center  II  as  well  as  in  the  Lockheed  Martin  Missiles  and  Space  (LMMS)  Spacecraft 
Product  Center  in  Sunnyvale  where  in  December  1997  it  was  used  to  support  a  successful  demonstration 
of  an  application  engineering  process  for  the  SBIRS  (Space-Based  Infrared  System)  Program. 


Workbench  Description 

The  Workbench  consists  of  a  graphical  user  interface  (GUI),  an  application  that  interfaces  with  an 
underlying  Oracle®  database,  and  an  ASCII  text  editing  tool  (TRF-2)  developed  by  Software  Architecture 
and  Engineering,  Inc.  It  mechanizes  the  domain  decision  model  and  can  incoiporate  the  adaptable 
components  that  are  developed  during  domain  engineering.  At  a  top  level,  the  Workbench  can  be 
described  in  terms  of  capabilities  to 

1.  automate  the  collection  and  evaluation  of  user  domain  decisions  and  application  specifications; 

2.  select  the  components  that  provide  the  needed  application  functionality; 

3.  tailor  ASCII  text-based  components  as  needed  to  satisfy  application  requirements. 

The  Workbench  makes  the  component  selection  process  and  tailoring  for  application  instantiation  virtually 
transparent  to  the  user.  During  a  Workbench  session,  the  user  is  guided  through  a  series  of  graphical 
screens  that  gather  application  context  information,  descriptions  of  needed  application  functionality,  and 
user  selections  for  Workbench  outputs.  Constituents  of  a  Workbench  session  are  illustrated  in  Figure  1 . 
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Reuse  Engineering  Workbench 


DOMAIN 
I  CONSTITUENTS 


Mission/Platform 

Editors 

|  Allow  user  to  describe: 

•  Mission  environment 

•  Platform  environment 
(environment  in  which 
the  software  operates) 


Subsystem 

Decision  Model 

•  Hierarchy  of 
decisions 

•  Dependencies 
between  decisions 

•  Handles  solution 
variabilities 


Test 


Design 
Regs  I 


Tailoring 

Parameters 


Component 

Inclusion 

Criteria 


Parameterized  Reuse 
Components 


r-! . .  ~7~1| 

Application 

Components 

JJ 

Code  tailored  to  specific  application 
Documentation  (Reqs,  Design, 

Test  Cases,  etc.) 


Figure  1  Workbench  Session  Constituents 

LMA  and  LMMS  installations  of  the  Workbench  are  configured  to  support  application  engineering  in 
spacecraft  flight  software  development  environments.  All  current  Workbench  installations  are  functionally 
identical.  (Lockheed  Martin  used  internal  funding  to  modify  the  decision  model  structure  in  its  Workbench 
installations  to  support  domain  components  developed  by  LMMS’s  Spacecraft  Product  Center.)  At  any 
time  during  a  Workbench  session,  the  user  can  access  on-line  context-sensitive  help  to  obtain  explanations 
of  Workbench  features.  Help  information  is  viewed  using  a  World  Wide  Web  browser  such  as 
Netscape®. 

On  entry  into  the  RSAS  Workbench,  the  user  is  presented  with  a  Mission  Selection  screen  as  depicted  in 
Figure  2. 
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Mission  Selection  Hindoo 
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Figure  2  RSAS  Mission  Selection  Screen 


The  Mission  Selection  screen  provides  buttons  for 

•  creating  a  new  mission, 

•  opening  an  existing  mission, 

•  importing  and  exporting  a  mission, 

•  cloning  a  new  mission  from  an  existing  mission, 

•  deleting  a  mission,  and 

•  renaming  a  mission. 

Once  the  selection  of  a  mission  option  has  been  selected,  the  user  moves  to  the  Mission  Editor  to  establish 
the  mission  context.  The  Mission  Editor  is  used  to  specify  the  external  environment  in  which  spacecraft 
operate;  a  constellation  of  spacecraft  is  permitted.  Features  include  a  palette  of  tools  for  specifying 
spacecraft  external  environment  (e.g.,  celestial  bodies  and  ground  stations),  an  annotation  tool,  and  object 
detail  capture  capability.  Detail  information  that  can  be  provided  by  the  user  includes  the  specification  of 
values  for  physical  attributes  such  as  gravity  fields.  Default  values  are  defined  as  required.  All  bit¬ 
mapped  graphics  are  replaceable  by  Workbench  users.  The  Mission  Editor  screen  is  shown  in  Figure  3. 
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Figure  3  RSAS  Mission  Editor  Screen 

Each  spacecraft  created  in  the  Mission  Editor  can  be  expanded  to  access  a  screen  in  which  the  user 
describes  the  flight  software  computational  environment.  This  screen — called  the  Platform  Editor — is 
shown  in  Figured  for  the  RSAS  Workbench  implementation. 


Figure  4  RSAS  Platform  Editor  Screen 

The  Platform  Editor  contains  a  palette  of  tools  for  describing  the  hardware  context  for  software.  The  user 
can  select  hardware  devices  from  a  pre-defmed  collection  of  computers,  sensors,  actuators,  and 
communication  buses.  Annotation  sheets  can  be  attached  to  devices  to  capture  special  information.  The 
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palette  includes  a  tool  that  is  used  to  allocated  subsystem  software  to  flight  computers.  Once  software  has 
been  allocated  to  a  computer,  that  computer  can  be  selected  and  expanded  to  access  the  subsystem  decision 
tree  for  the  specification  of  application  functionality.  The  decision  model  root  screen  is  shown  in  Figure  5. 
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Guidance,  Navigation  and  Control 

_LI 

(PBYD 
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JLl 

(STRUCT) 

Structures  and  Mochanisns 

_d 

(THERM) 

Thernal  Subsysten 

Back 

A  11 

Figure  5  RSAS  Decision  Model  Root  Screen 


The  decision  model  root  screen  is  the  starting  point  for  the  user  to  select  and  tailor  decisions  for  domain 
subsystems.  The  top  section  of  the  user  screen  displays  the  current  context  for  user  decisions.  For  each 
selected  subsystem,  the  user  is  guided  through  a  decision-making  process  that  results  in  the  later 
adaptation  of  reusable  components  for  a  specific  application  instantiation.  Decisions  at  the  subsystem  level 
can  be  constrained  by  information  provided  in  the  Mission  and/or  Platform  Editors,  or  be  dependent  on 
user  decisions  in  other  subsystems.  In  the  RSAS  framework,  the  user  identifies  spacecraft  subsystem 
functionality  and  the  implementing  algorithms.  Decisions  made  by  users  increase  in  detail  to  a  point  where 
algorithm  configuration  parameters  are  specified  (see  Figure  6). 


nission  :  RSAS_ Tutorial 
spacecraft  :  UMMflfCD.5795 
computer  ;  UNKAMED_5751 
nission  phase  :  START 
tracked  spacecraft  :  UWtfjO.5795 

Solar  pressure  parameters 

Solar  Honantun  Flux  (k*/W»**2>  ]  4 . 529  80041  E-06 

Cross  sectional  area 

d  constant  <i***2)  I  1  .OOQOOOOOE+ 

J  variable  No  user  function  defined 

Reflectivity  coefficient 

(t  constant  I  1  •  OOOOOOOOE+ 

J)  variable  No  user  function  defined 

^  Back  A 


Figure  6  Example  of  a  Decision  Model  Parameter  Screen 
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The  RSAS  Workbench  permits  the  user  to  add  personal  software  modules  to  the  instantiation  of 
applications.  (It  is  assumed  these  modules  conform  to  the  domain  architecture.)  This  feature  adds 
flexibility  during  application  engineering  to  accommodate  changes  in  domain  technology.  Once  decisions 
have  been  completed,  the  user  returns  to  the  Platform  Editor  from  which  the  Component  Generation  screen 
(Figure  7)  is  accessed. 


Figure  7  RSAS  Component  Generation  Screen 


In  the  Component  Generation  screen,  the  user  selects  the  categories  of  reusable  assets  that  are  to  be  output. 
For  the  flight  software  domain,  output  options  include  the  production  of  code  for  a  target  processor  or  a 
simulation  environment  in  which  the  code  may  contain  statements  to  support  error  detection  needs.  Figure 
8  illustrates  the  Workbench  session  process  flow  for  the  current  implementation  within  the  spacecraft  flight 
software  domain. 
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Figure  8  Workbench  Session  Process  Flow 


Domain  Adaptation 

The  Workbench  tool  can  be  adapted  to  any  product-line  environment  that  involves  a  complex  decision¬ 
making  process.  Adaptation  requires  modifications  to  the  following  Workbench  areas: 

1 .  domain  decision  model(s); 

2.  user  screens  for  the  domain  decision  model(s); 

3.  mission  and  platform  editors; 

4.  help  screens  and  “html”  files  for  on-line  help; 

5.  domain  specific  graphics  for  icons; 

6.  TRF-2  language  scripting  to  ASCII  text  assets  for  automated  tailoring  (optional). 

The  major  cost  for  adapting  the  Workbench  to  a  domain  is  a  function  of  the  number  of  decision  groups  in 
the  domain  decision  model.  (One  decision  group  is  roughly  equivalent  to  one  Workbench  screen  such 
shown  in  Figures  6  and  7.)  An  estimate  of  this  cost  is  presented  in  Table  2  where  it  is  assumed  that 
decision  models  are  available  for  incorporation  into  the  Workbench.  The  estimate  is  expressed  in  terms  of 
work-hours  per  decision  group.  The  cost  for  modifying  Workbench  icons  is  very  small  and  is  not 
included  in  Table  2. 


Table  2  Domain  Adaptation  Cost  Estimates 


Workbench  Adaptation 
Task 

Cost  per  Decision  Group 
(hours/decision  group) 

Decision  model  incorporation 

0.9 

User  screen  development 

4.8 

Help  screen  development 

1.3 

TRF-2  incorporation  (optional) 

4.7 
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Constituents  of  the  Workbench  host  environment  are  listed  in  Table  3. 


Table  3  Workbench  Host  Environment 


A 

Development 

O 

F>erational 

Software 

Hardware 

Software 

* 

GNAT  Ada  compiler  version  3.09 

Sun  SPARC  station  2 

Solaris  2.5  or  2.5.1 

PRO*C  pre-compiler  (ORACLE  product) 

32  Mbytes  RAM 

CDE  (Common  Desktop  Environment) 

UIM/X  GUI  builder  version  2.9 

100  Mbytes  disk  space 

Netscape  Navigator  (WWW  Server 

Motif  developer  kit 

FileMaker  Pro  3.0  (optional) 

Color  Terminal 

Optional) 

Shared  Libraries  (suggested) 

libMrm.so.3 

libXm.so.3 

libXt.so.5.0 

libXl  l.so.5.0 

libm.so.l 

libc.so.l 

TRF-2 

Access  To  Oracle  Database  (via  SQL*NET) 
Oracle  Product  Version  at  least  7.0.16 

Summary 

This  report  has  provided  an  overview  of  the  application  engineering  Workbench  developed  by  Lockheed 
Martin  Astronautics  under  contract  to  the  AFRL  Space  Vehicles  Directorate.  The  Workbench  was 
developed  successfully  on  a  contract  that  had  as  its  primary  objective  the  creation  of  an  application 
engineering  tool  for  the  spacecraft  flight  software  domain.  It  incorporates  a  domain  decision  model  that  is 
used  to  determine  the  selection  and  possible  tailoring  of  reusable  components  for  the  instantiation  of 
domain  applications.  Workbench  users  specify  application  attributes  via  a  graphical  interface.  They  are 
assisted  by  context-sensitive  on-line  help  information  that  is  available  through  a  Web  browser  such  as 
Netscape  . 


Although  the  Workbench  was  developed  to  simplify  and  automate  the  reuse  of  spacecraft  flight  software,  it 
facilitates  application  engineering  in  any  product-line  environment  where  the  reuse  of  assets  is  governed  by 
a  complex  decision-making  process.  It  can  be  adapted  for  non-spacecraft  applications  where  domain 
engineering  tasks  have  been  completed.  The  Workbench  is  installed  at  the  AFRL  Space  Vehicles 
Directorate  as  well  as  at  LMA  in  Denver  and  LMMS  in  Sunnyvale. 


9 


L 


DISTRIBUTION  LIST 


AUL/LSE 

Bldg  1405  -  600  Chennault  Circle 

Maxwell  AFB,  AL  361 12-6424  1  cy 

DTIC/OCP 

8725  John  J.  Kingman  Rd,  Suite  0944 
Ft  Belvoir,  V  A  22060-62 18  2  cys 

AFSAA/SAI 

1580  Air  Force  Pentagon 

Washington,  DC  20330-1580  Icy 

AFRL/PSOTL 

Kirtland  AFB,  NM  871 17-5776  2  cys 

AFRL/PSOTH 

Kirtland  AFB,  NM  871 1 7-5776  1  cy 

Lockheed  Martin  Corporation 
Lockheed  Martin  Astronautics 
P.O.  Box  179 

Denver,  CO  80201-0179  1  cy 

AFRL/VS/Dr  Fender 

Kirtland  AFB,  NM  871 1 7-5776  1  cy 

Official  Record  Copy 

AFRL/VSSS/Ross  H.  Wainwright  2  cys 


10 


